[Affected versions]:
Nightly 70.0a1

[Affected platforms]:
Platforms: All

Steps :

1. Launch the Firefox browser and reach Office 365.
2. Open a new Word document.
3. Type some text and Hit SPACE multiple times

Expected Results :
The text cursor should move accordingly without glitching.

Actual Results :
The mouse cursor glitches, sometimes jumps forward 2 spaces and then jumps back after hitting space.
This glitch is more visible if the user HOLDS the SPACE bar down.
Note: please note that in the attached video is not that visible since it has a poor framerate.

This only occurs on Office Online only. (I cannot reproduce this using simple contenteditable). This might be site's issue.

Ksenia, could you take a look please?

This is not reproducible 100% of the time for me, most of the times it works ok.
On every input event there is a constant DOM modification via removeChild/appendChild, so this could be a performance issue.

I've attached a reduced test case. Similarly, most of the time it works ok, but sometimes the browser freezes up (not happening in Chrome).
Also a link to perf profile from the original website https://perfht.ml/34dt1y6

Thank you, :ksenia! According to the profile, most time spends on reflow caused by Element.getBoundingClientRect() which is called by a input event handler. https://perfht.ml/2Wp9b1V

Before dispatching input event, of course there is a change of a text node at least. However, the reflow computes new layout really deeply. If it's caused by this performance, I don't understand what's going on. But I guess that the jumping is caused by setting Selection by editor which is outdated. Unfortunately, I cannot reproduce this bug with ksenia's testcase even on slower debug build.

Oh, before dispatching input event, editor calls ScrollIntoView() and it flushes pending reflow which includes the change caused by typing text.
https://searchfox.org/mozilla-central/rev/61f224ec08ddc6f9a93ac45c8c3c5f7159be7c2a/editor/libeditor/EditorBase.cpp#983,1005,1032

So, it seems that the getBoundingClientRect() is called after Office changed something.

Hmm, I don't see any redundant (outdated) Selection::Collapse() calls...

Now I cannot reproduce this now. Rares, could you still reproduce this? comment #6's code is still existed.

Yes, this issue still occurs on my end in Release, Beta 77.0b7 and our latest Nightly build 78.0a1 (2020-05-18).

Currently, I'm working on rewriting the code normalizing whitespaces. Once it'll be landed, our editor won't modify text nodes multiple times at inserting a whitespace. I hope, it fixes this or at least makes the symptom better.

I don't seem to see the glitching behavior in the recent versions. Both of Release Fx 137 with the pref editor.white_space_normalization.blink_compatible disabled) and Nightly Fx 139 with the pref editor.white_space_normalization.blink_compatible enabled work for me. Something may have changed on the site?

Hi Rares, is this still reproducible for you?

I cant reproduce this issue in our latest builds, I will close this Works For Me. Thank you @ Hsin-Yi Tsai for the updates.